1. Field of the Invention
The present invention relates to a transaction processing system, and in particular to implementation of transaction processing in response to requests from plural customers.
2. Description of the Related Art
The transaction system is a system for efficiently executing a lot of processing requests in such a manner as to assure consistency in a basic line of corporate information system such as financial trading and ordering/order receiving. In general, a client/server system is so constructed that a client (terminal) issues a request and a server executes the main body of transaction processing by accessing a database as required. A processing program executing an actual transaction on the server is called service.
The service providing side in the transaction system is called a service provider. For example, in the retailing bank business, ATMs or tellers are clients, and the basic system including a customer's account database is a server. In this case, the bank is the service provider, which provides services such as withdrawal and deposit transactions.
Transaction processing middleware used on the server side is a transaction monitor. The transaction monitor mainly takes the following two parts.
(1) The transaction monitor receives processing requests sent from clients and queues the processing requests by taking into account request priorities and crowding levels on the server to forward control of the respective requests to appropriate server programs (service) one by one, thus making effective use of server resources.(2) The transaction monitor detects errors or faults caused during execution of processing. If the processing has completed successfully, it carries out result writing (committing) operation, while if the processing has not completed successfully, it carries out cancel (rollback) or re-run operation. Thus the transaction monitor assures consistency of the transaction processing.
FIG. 18 shows a typical configuration of the transaction monitor.
As shown, a transaction monitor 209 is located on a server 215, while client programs 201, 202 issuing processing requests are located on client terminals 221, 222, respectively.
In general, the server 215 is a UNIX server, a mainframe computer or the like, while the client terminal is a personal computer, an ATM terminal or the like.
The transaction monitor 209 includes request queues 210 and 211, a scheduler 204 and a transaction execution module 207.
The processing request for a service is typically transferred from the client 221 or 222 to the server 215 in the form of a message (electronic text). Therefore, the transaction monitor has a communication function module so that the transaction monitor receives a processing message by controlling its own communication function module.
The message received is stored in the transaction monitor 209 as a processing request. Since two or more requests are usually kept waiting in the transaction monitor 209, the transaction monitor 209 uses the queues 210, 211 as a First-In First-Out data structure to store the requests in the order of input. The requests stored are extracted from the queues 210, 211 in the order of storage as soon as one of resources (CPU, memory etc.) in the transaction execution module 207 becomes available, and processed by corresponding service programs 206.
(Scheduling and Load Balancing)
Scheduling is to extract a request from a queue and move the request to the execution of service program processing for the request. Efficient scheduling is necessary to increase the efficiency of the transaction processing system.
In particular, if there exist plural resources (processor, server etc.) that provide services, processing efficiency depends a lot on how to allocate the requests to the plural resources. Allocating requests to the plural resources to increase the efficiency of transaction processing is called load balancing. Thereinafter, including both the scheduling above-mentioned and load balancing operations, the entire allocating process of the requests to the resources may be referred as “scheduling”.
As one approach to scheduling, a method of balancing load by increasing or decreasing the number of processes for providing a service is known. An outline of the method will be described with reference to FIG. 19.
In FIG. 19, requests 301 to 309 are stored in a request queue 300. These requests are supposed to be processed by processes 310 to 313 one by one. The term “process” is a unit of program to be processed on a computer, and the unit is a combination of one virtual address space, a program loaded on the space, data and a CPU register indicative of an execution state of the program.
In the example of FIG. 19, the same transaction processing program (service program) is loaded in all the processes. If free spaces are available in the CPU of the computer, the number of services to be provided concurrently is increased by increasing the number of processes so that the utilization factor of the CPU can be improved.
In other words, increasing or decreasing the number of processes allocated to transactions make it possible to control processing throughput to the transactions (the number of requests to be processed in a unit time).
FIG. 19A shows a case where a very small number of requests are stored in the queue 300. In this case, the transaction monitor allocates a small number of processes (310, 311) to the service concerned according to the number of requests.
FIG. 19B shows a case where a large number of requests arrive and hence the number of requests queued in the queue 300 increases. In this case, the transaction monitor monitors conditions in the queue to increase the number of processes to be allocated to the service (310 to 313).
FIG. 19C shows a case where incoming messages are reduced and the length of the queue becomes short. In this case, the transaction monitor deallocates the idling process 313 from the service and allocate it to another service or task. By associating the length of the queue with the number of processes to be allocated, it becomes possible to improve transaction efficiency within a range of CPU resources.
And, in case that there are plural servers to be controlled by the transaction monitor, a system shown in FIG. 20 is used for balancing load among servers.
Suppose that there are three servers (420 to 422), and that a queue 400 of one of the servers (server 420) including processes 410 and 411 becomes longer than the other queues 401, 402 for reasons of server's processing capacity, crowding level or the like. In this case, a processing program 431 on the client 430 detects this state and controls itself to send messages by priority to shorter queue servers 421, 422 which includes processes 412n, 413 and processes 414, 415, respectively. Thus, the queues can be balanced in length among the plural servers to improve the total throughput.
(Message Broker)
Example applications of the transaction monitor for a further advanced multi-transaction processing system include a message broker.
A normal transaction processing system has a one-to-one correspondence between a message and a service, but a message broker performs processing by passing one message among plural services by recursively invoking. The message broker stores in the transaction monitor a service flow (business flow), which designates what services and in what sequence the services are invoked for the message. The services to be invoked may be located on the same server as the transaction monitor or another independent stand-along server.
FIG. 21 shows a configuration of the message broker.
Client programs 501, 502 from which processing requests are issued are located on client terminals, respectively. A transaction monitor 509 is located on a transaction processing server.
Service programs A520 and B521 for providing business services are loaded on different servers 530, 531 (or the same server) through a message adapter 515. The terminals and the servers are connected with each other through message communications lines. The transaction monitor 509 includes request queues 510, 511 and a scheduler 504 for deciding the sequence of request processing.
Compared to the normal transaction processing system (FIG. 18), the message broker adds an extension to the transaction execution module (207 in FIG. 18) to constitute a service flow execution routine 507.
The service flow execution routine 507 manages the execution of a service flow defined by the service provider, not just initiate and execute a service program according to a message.
Since the message broker allows the execution of a service flow 506 on the transaction monitor, it can combine plural service programs to construct more complicated service structure.
(Node Replacement During Operation)
In the message broker the service flow may often be altered or changed due to an update or addition of business service. It is undesirable to stop the entire system each time the service flow is altered or changed. For this reason, a mechanism for changing only the service flow without stopping the system operation is highly required.
One method is to divide the processes executing the service flow into two groups (active group and standby group). In this case, the active group executes the unchanged flow while re-loading a new service flow to the standby group. Upon completion of loading, message routing is switched from the active group to the standby group in the continuation of the system's operation.
Another method is to provide routing enable and disable modes for each service node. In this case, a node to be replaced is changed to routing disable mode, thereby prohibiting input of any message to the node upon re-loading of a new service flow to the node.
The above-mentioned transaction or message broker processing systems are known from the following publications: Japanese Patent Laid-Open Application No. 09-062624 (JP-A-09-062624) (Processing System for On-line Transaction); Japanese Patent Laid-Open Application No. 06-243077 (JP-A-06-243077) (Distributed Transaction Processing System); Japanese Patent Laid-Open Application No. 08-063432 (JP-A-08-063432) (Transaction Batch Processing System in Consideration of Priority); Japanese Patent Laid-Open Application No. 06-052121 (JP-A-06-052121) (Batch processing-Real Time Processing Sorting Type Transaction Processing System); Japanese Patent Laid-Open Application No. 07-073143 (JP-A-07-073143) (Time Band-Based Priority Control Transaction Processing System); and Japanese Patent Laid-Open Application No. 10-040117 (JP-A-10-040117) (Task Control type On-line Transaction Processing System for Maintaining High Response).